Currently, distributed embedded smart devices that are connected to networks, such as a wide area network, Internet, or wireless network, are used in a variety of application areas, such as banking, ticket reservation, kiosk, manufacturing, marketplaces, and payment counters by way of example. The continuing rapid growth of smart devices coupled with a faster pace of application development is leading to a problem of maintainability and scalability of these smart devices.
To make these smart devices scalable and maintainable in the current context, frequent updates of software or firmware installed on these smart devices are necessary because consumers expect their devices to stay updated to the latest application releases. Accordingly, updating these smart devices in a timely manner Over-The-Air (OTA) has been an answer to this expectation.
Unfortunately, a major challenge to executing this OTA updating is the lack of resources, such as insufficient flash memory, RAM, and/or CPU power by way of example, in these smart devices. The limited bandwidth connecting these smart devices often negatively affects the performance of these OTA updates. Additionally, these updates often require a good amount of data transmission security to be implemented. This in turn requires a network with higher bandwidth and higher processing capability in these smart devices, neither of which is always available.
By way of example, a conventional deployment of an OTA update solution is shown in FIG. 1 where a device management (DM) server 14 uses Open Mobile Alliance Device Management (OMA-DM) and Open Mobile Alliance Download Over-The Air) (OMA-DL) protocols in conjunction with a content server 16 to deliver update content to a client computing device 12 (also referred to herein in the examples herein as an embedded device or a resource constrained computing device). Unfortunately, these protocols are not efficient from both protocol semantics (i.e. Message Exchanges) as well as syntax (i.e. Payload Structure) perspective for the client computing device 12 which has limited computing resources
A more detailed functional block diagram of an architecture for an OMA-DM and OMA-DL based solution for implementing this conventional deployment of an OTA update is illustrated in FIG. 2. In this example, at step 100 the DM server 14 notifies a DM Transport Client module of the client computing device 12 about an available update, i.e. in this example a server initiated update, although other options for initiating the updated may be used, such as a request for an update initiated from the client computing device 12 by way of example. At step 102, the DM Transport Client module of the client computing device 12 queries device capability information (DevInfo) from a Configuration Manager module of the client computing device 12. At step 104, the DM server 14 and the Transport Client module of the client computing device 12 exchange OMA-DM commands to establish a DM Session using the DevInfo received in step 102.
At step 106, the DM Transport Client module of the client computing device 12 updates a Firmware Update Management Object Database (FUMO DB) of the client computing device 12 with the details created in step 104. At step 108, a Download Manager module of the client computing device 12 periodically monitors the FUMO DB for a new entry and collects Content Server 16 related information from the FUMO DB, in case of a new entry in the FUMO DB. At step 110, for a new entry in the FUMO DB, the Download Manager module of the client computing device 12 initiates a software download following OMA-DL and using the information obtained in step 108 and then updates the FUMO DB upon completion.
At step 112, an Update Manager module of the client computing device 12 periodically checks FUMO DB for any newly downloaded upgraded software. At step 114, in case the Update Manager module of the client computing device 12 finds newly downloaded upgraded software, the Update Manager module utilizes a device specific Updater Application module of the client computing device 12 to update the client computing device 12 with the new upgraded software using a conventional patch upgrade technique. At step 116, upon completion the Update Manager module of the client computing device 12 notifies the DM server 14 about the software update status using OMA-DM commands. Unfortunately, as noted earlier this convention deployment process does not address any of the challenges related to situation with limited bandwidth and/or lack of resources noted above.